While fuzzing I continued to hit "SecurityError: The operation is insecure." when calling the canvas' toDataURL method and I wasn't exactly sure what was happening. I have attached two cleaned up test cases from my fuzzer. One that works as I would expect and one that raises SecurityError. The test case that errors I have narrowed the issue down to two operations. So this may not be an issue but this does seems strange. Thought?

From the view of spec[1], the toDataURL(), toBlob(), and getImageData() methods check the flag and will throw a "SecurityError" DOMException rather than leak cross-origin data. [1]: https://html.spec.whatwg.org/multipage/scripting.html#a-serialisation-of-the-bitmap-as-a-file I think the error happens since we had operation like [2] in program. [2]: ctx.filter='invert(1%)'; Once filter() was called, it sets to write-only[3] mode for canvas. After that, calling ToDataURL() will hit writeonly check and throw out security error[4]. [3]: https://dxr.mozilla.org/mozilla-central/source/dom/canvas/CanvasRenderingContext2D.cpp#444 [4]: https://dxr.mozilla.org/mozilla-central/source/dom/html/HTMLCanvasElement.cpp#629 I think this error should be reasonable because calling toDataURL() shouldn't be in write-only mode. I will close this bug. Re-open it if I got anything wrong.

(In reply to Vincent Liu[:vliu] from comment #2) > From the view of spec[1], the toDataURL(), toBlob(), and getImageData() > methods check the flag and will throw a "SecurityError" DOMException rather > than leak cross-origin data. Makes sense. > I think the error happens since we had operation like [2] in program. > > [2]: ctx.filter='invert(1%)'; > > Once filter() was called, it sets to write-only[3] mode for canvas. After > that, calling ToDataURL() will hit writeonly check and throw out security > error[4]. This is not a cross-origin filter. Why is it marked tainted? The testcase seems like something you could reasonably expect to work without triggering a CSP exception.

I believe this is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1307740 which has been fixed for FF52+

Agreed with comment 4. This reproduces with Fx50 but went away in Fx51 (which bug 1307740 was backported to).